.. :validated: 3.1.0

Отладка работы службы SSSD
==============================================================================

Служба **SSSD** предоставляет две основные функции: получение информации о пользователях и их аутентификацию. Каждая из этих функций использует свои программные интерфейсы, поэтому должна рассматриваться отдельно. Однако успешная аутентификация возможна, только если информация о пользователе получена успешно, поэтому, если что-то не работает, то в первую очередь нужно убедиться, что возможно получить хотя бы информацию о пользователе с помощью команд ``getent`` и ``id``:

.. code-block:: bash

    getent passwd $USER

Результат выполнения:

.. code-block:: bash

    admin:*:1421600000:1421600000:Administrator:/home/admin:/bin/bash

Выполнить команду ``id``:

.. code-block:: bash
    
    id $USER

Результат выполнения:

.. code-block:: bash

    uid=959800000(admin) gid=959800000(admins) группы=959800000(admins),1001(astra-admin),113(lpadmin)

Журналы отладки SSSD
------------------------------------------------------------------------------

Служба **SSSD** состоит из множества компонентов и для настройки каждого из них в конфигурационном файле предназначена отдельная секция (например, за настройки монитора отвечает секция ``[sssd]``, а **Бэкенд** настраивается в секции ``[domain/...]``), поэтому для включения отладки конкретного компонента в его секции следует задать параметр ``debug_level=N``, где **N** - это число от 1 до 10.

Уровни отладки 1-3 регистрируют сбои, а уровни 8-10 обеспечивают излишнюю детализацию, которая затрудняет быстрый анализ журналов, поэтому для решения большинства проблем начать лучше с шестого уровня. Открыть конфигурацию командой:

.. code-block:: bash

    sudo cat /etc/sssd/sssd.conf

Результат выполнения:

.. code-block:: bash
        
    [domain/ald.company.lan]
    debug_level = 10
    id_provider = ipa
    ...
    [sssd]
    debug_level = 10
    services = ifp
    domains = ald.company.lan
    [nss]
    debug_level = 10
    homedir_substring = /home
    ...

Уровень отладки можно менять не только через конфигурационный файл, но и «на лету» без перезагрузки службы **SSSD**, отправляя ей команды через **SBus** с помощью утилиты **sssctl** из пакета **sssd-tools**. Очистить логи, чтобы удобно было смотреть отладочную информацию:

.. code-block:: bash

    sudo sssctl logs-remove

Изменить уровень отладки командой и просмотреть в лог файле изменение ``grep`` 'Debug level changed':

.. code-block:: bash

    sudo sssctl debug-level 6
    sudo cat /var/log/sssd/sssd.log | grep 'Debug level changed'

Результат выполнения отображает начало нужного события:

.. code-block:: bash

    (2023-08-20 22:17:00): [sssd] [server_common_rotate_logs] (0x0010): Debug level changed to 0x07f0

Повысить уровень логирования до 8:

.. code-block:: bash

    sssctl debug-level 8
    cat /var/log/sssd/sssd.log | grep 'Debug level changed'

В результате можно увидеть два события начало и конец. Это нужно для удобного просмотра лога, чтобы знать где искать интервал отладочной информации от и до:

.. code-block:: bash

    ...[sssd] [server_common_rotate_logs] (0x0010): Debug level changed to 0x07f0
    ...[sssd] [server_common_rotate_logs] (0x0010): Debug level changed to 0x37f0

Выбрать все строки между кодами смены уровня отладки **0x07f0** и **0x37f0** можно с помощью ``regex`` запроса:

.. code-block:: bash

    cat /var/log/sssd/sssd.log | grep -zoP '(?<=0x07f0)(?s).*(?=0x37f0)'

В операционной системе Astra Linux журналы отладки хранятся в папке */var/log/sssd*, по одному файлу журнала на каждый компонент. **Ответчики** пишут в файлы с именами *SSSD_$service*, например, собеседник **NSS** пишет в файл */var/log/sssd/sssd_nss.log*. Сообщения от **Бэкенда** пишутся в файл с именем *sssd_$domainname.log*. Есть еще журналы вспомогательных процессов, таких как *ldap_child.log и krb5_child.log*.

Прежде чем погружаться в изучение журналов и файлов конфигурации, желательно внимательно ознакомиться с описанием архитектуры службы **SSSD**.

Во многих случаях полезно воспроизвести ошибку после очистки кэша, чтобы исключить его влияние, но важно помнить, что в локальной базе кэшируются также и учетные данные, поэтому не стоит удалять кэш, если работа идет в автономном режиме. А также важно обратить внимание, что приведенные примеры сообщений отладки могут меняться для последующих релизов.

Общие рекомендации
------------------------------------------------------------------------------

Если команды ``getent`` или ``id`` не выводят вообще никакой информации о пользователе или группе, то нужно проверить:

* Работу службы разрешения имен командой ``ping dc-1`` и, указаны ли в */etc/resolv.conf* правильные DNS-сервера.

* Работает ли служба с помощью команды ``systemctl status sssd``.

* Конфигурацию */etc/nsswitch.conf*, что модуль **sss** указан для следующих баз данных: **passwd**, **group**, **shadow**, **services**, **netgroup**, **sudoers**, **automount**.

* Поведение команды ``id`` на контроллере домена ALD Pro.

* Доходит ли запрос до **Ответчика**. Для этого в разделе ``[nss]`` установите ``debug_level = 6`` и перезапустите службу **sssd**. 

Приведем пример успешного запроса информации по пользователю.

.. code-block:: bash

    [sssd[nss]] [get_client_cred] (0x4000): Client creds: euid[10327] egid[10327] pid[18144].
    [sssd[nss]] [setup_client_idle_timer] (0x4000): Idle timer re-set for client [0x13c9960][22]
    [sssd[nss]] [accept_fd_handler] (0x0400): Client connected!
    [sssd[nss]] [sss_cmd_get_version] (0x0200): Received client version [1].
    [sssd[nss]] [sss_cmd_get_version] (0x0200): Offered version [1].
    [sssd[nss]] [nss_getby_name] (0x0400): Input name: admin

Если команда достигает **Ответчика** **NSS**, передается ли она **Поставщику** данных (Data Provider). Неудачный запрос может выглядеть так:

.. code-block:: bash

    [sssd[nss]] [cache_req_search_dp] (0x0400): CR #3: Looking up [admin@ipa.test] in data provider
    [sssd[nss]] [sss_dp_issue_request] (0x0400): Issuing request for [0x41e51c:1:admin@ipa.test@ipa.test]
    [sssd[nss]] [sss_dp_get_account_msg] (0x0400): Creating request for [ipa.test][0x1][BE_REQ_USER][name=admin@ipa.test:-]
    [sssd[nss]] [sss_dp_internal_get_send] (0x0400): Entering request [0x41e51c:1:admin@ipa.test@ipa.test]
    [sssd[nss]] [sss_dp_req_destructor] (0x0400): Deleting request: [0x41e51c:1:admin@win.trust.test@win.trust.test]
    [sssd[nss]] [sss_dp_get_reply] (0x0010): The Data Provider returned an error [org.freedesktop.sssd.Error.DataProvider.Offline]
    [sssd[nss]] [cache_req_common_dp_recv] (0x0040): CR #3: Data Provider Error: 3, 5, Failed to get reply from Data Provider
    [sssd[nss]] [cache_req_common_dp_recv] (0x0400): CR #3: Due to an error we will return cached data    

Успешно обработанный запрос напротив будет выглядеть так:

.. code-block:: bash

    [sssd[nss]] [cache_req_search_dp] (0x0400): CR #3: Looking up [admin@ipa.test] in data provider
    [sssd[nss]] [sss_dp_issue_request] (0x0400): Issuing request for [0x41e51c:1:admin@ipa.test@ipa.test]
    [sssd[nss]] [sss_dp_get_account_msg] (0x0400): Creating request for [ipa.test][0x1][BE_REQ_USER][name=admin@ipa.test:-]
    [sssd[nss]] [sss_dp_get_reply] (0x1000): Got reply from Data Provider - DP error code: 0 errno: 0 error message: Success
    [sssd[nss]] [cache_req_search_cache] (0x0400): CR #3: Looking up [admin@ipa.test] in cache

Если запрос к **Поставщику** данных успешно завершен, но по-прежнему не отображаются результаты, следует переходить к журналам **Бэкенда**.

Отладка Бэкенда
------------------------------------------------------------------------------

**Бэкенд** выполняет несколько различных операций, поэтому бывает трудно сразу понять, в чем заключается проблема. На самом высоком уровне **Бэкенд** выполняет следующие шаги в указанном порядке:

1. **Бэкенд** получает запрос от клиентской библиотеки и решает, к какому серверу следует подключиться для его обработки. Этот шаг может включать в себя поиск по **SRV**-записям.

2. **Бэкенд** устанавливает соединение с сервером и проходит аутентификацию, используя учетные данные из keytab-файла хоста, если это требуется.

3. Как только соединение установлено, **Бэкенд** отправляет запрос на поиск информации, поэтому вы должны увидеть в запросе критерии фильтрации, базовую запись и запрашиваемые атрибуты.

4. После того, как поиск завершится, соответствующие записи будут сохранены в кэше. Код состояния возвращается **собеседнику**. Установите ``debug_level=6`` в разделе ``[domain/]``, перезапустите службу и выполните еще раз неудачный поиск информации о пользователе. При отладке работы **Бэкенда** в первую очередь убедитесь, что **Бэкенд** находится в режиме **онлайн**, сделать это можно с помощью утилиты **sssctl**.

.. code-block:: bash

    sudo sssctl domain-status ald.company.lan

Результат выполнения:

.. code-block:: bash

    Online status: Online

    Active servers:
    IPA: dc-1.ald.company.lan

    Discovered IPA servers:
    - dc-1.ald.company.lan

Проверить, можно ли установить соединение с теми же параметрами безопасности, которые использует **SSSD**:

.. code-block:: bash

    kinit -k && klist

Результат выполнения:

.. code-block:: bash

    Ticket cache: KEYRING:persistent:959800000:krb_ccache_pMxi5Bu
    Default principal: host/dc-1.ald.company.lan@ALD.COMPANY.LAN

    Valid starting       Expires              Service principal
    20.08.2023 23:15:25  21.08.2023 23:15:25  krbtgt/ALD.COMPANY.LAN@ALD.COMPANY.LAN

Проверить запрос в **LDAP**, где Ключи ``-H`` и ``-ZZ`` делают запрос ближе к тому, как служба **SSSD** взаимодействует с каталогом:

.. code-block:: bash

    ldapsearch –ZZ –H ldap://dc-1.ald.company.lan -b uid=admin,cn=users,cn=accounts,dc=ald,dc=company,dc=lan cn

Результат выполнения:

.. code-block:: bash

    # admin, users, accounts, ald.company.lan
    dn: uid=admin,cn=users,cn=accounts,dc=ald,dc=company,dc=lan
    cn: Administrator

Для отладки **GSSAPI** аутентификации команду ``kinit`` можно использовать в сочетании с переменной окружения ``KRB5_TRACE``. Если установлен для **Бэкенда** десятый уровень, то информация о трассировке Kerberos аутентификации будет отражаться также в журнале *ldap_child.log*.

.. code-block:: bash

    sudo i
    set +o history
    env KRB5_TRACE=/dev/stdout kinit <<< AstraLinux_176
    set -o history
    exit

Результат выполнения:

.. code-block:: bash

    [23001] 1696515238.426608: Getting initial credentials for admin@ALD.COMPANY.LAN
    [23001] 1696515238.426610: Sending unauthenticated request
    [23001] 1696515238.426611: Sending request (191 bytes) to ALD.COMPANY.LAN
    [23001] 1696515238.426612: Initiating TCP connection to stream 10.0.1.11:88
    [23001] 1696515238.426613: Sending TCP request to stream 10.0.1.11:88
    [23001] 1696515238.426614: Received answer (514 bytes) from stream 10.0.1.11:88
    [23001] 1696515238.426615: Terminating TCP connection to stream 10.0.1.11:88
    [23001] 1696515238.426616: Response was from master KDC
    ...
    [23001] 1696515238.426651: Storing admin@ALD.COMPANY.LAN → krb5_ccache_conf_data/pa_type/krbtgt\/ALD.COMPANY.LAN\@ALD.COMPANY.LAN@X-CACHECONF: in KEYRING:persistent:1421600000:krb_ccache_kFlzpn6

Необходимо проверить, присутствуют ли на сервере все атрибуты, необходимые для службы **SSSD**, правильно ли указана база поиска, особенно для доверенных поддоменов. По возможности, выполнить такой же поиск вручную утилитой **ldapsearch**.

Устранение неисправностей аутентификации, изменения пароля и контроля доступа
------------------------------------------------------------------------------

Если информация о пользователе может быть успешно получена, но аутентификация не проходит, то в первую очередь нужно смотреть журнал */var/log/auth.log* на предмет сообщений от **pam_sss**. Аутентификация начинается в **PAM**-стеке на фазе **auth** и выполняется с помощью провайдера аутентификации (auth_provider) службы **SSSD**. Однако, не все запросы на аутентификацию проходят через **SSSD**, например, аутентификация по **SSH** происходит непосредственно в **SSHD**, а **SSSD** взаимодействует с **PAM** стеком только на фазе **account**. Контроль доступа начинается в **PAM** стеке на фазе **account** и выполняется с помощью провайдера доступа (access_provider) службы **SSSD**.

Смена пароля начинается на стороне **PAM** стека на фазе **password** и выполняется с помощью провайдера смены пароля (chpass_provider) службы **SSSD**.

Аутентификация через **PAM** стек происходит по следующему шаблону:

1. Приложение с поддержкой **PAM** аутентификации начинает диалог. В зависимости от настроек **PAM**-стека в диалог может быть вовлечен модуль **pam_sss**. Для отладки процесса аутентификации, сначала нужно проверить журнал */var/log/auth.log* на предмет того, есть ли вообще обращения к **pam_sss**. Если нет упоминания **pam_sss**, скорее всего, **PAM** стек настроен неправильно. Если обращения к **pam_sss есть**, нужно включить отладку для **Ответчика** **PAM**.

2. **Ответчик** **PAM** службы **SSSD** получает запрос на аутентификацию и в большинстве случаев пересылает его **Бэкенду**. Важно обратить внимание, что в отличие от запросов на идентификацию, запросы на аутентификацию и контроль доступа обычно не кэшируется и всегда завершаются обращением к **серверу**. В некоторых случаях это может приводить к задержкам, но это достаточно важно, потому что дополнительные группы в GNU/Linux устанавливаются только в момент входа в систему.

Журналы **собеседника** **PAM** должны показывать запросы, которые пришли от **PAM**-стека и были перенаправлены на **Бэкенд**. Если отображается запрос на аутентификацию к **собеседнику** **PAM**, но получается ошибка от **Бэкенда**, важно проверить журналы **Бэкенда**.

Пример ошибки может выглядеть как:

.. code-block:: bash

    [sssd[pam]] [sss_dp_issue_request] (0x0400): Issuing request for [0x411d44:3:admin@ipa.example.com]
    [sssd[pam]] [sss_dp_get_account_msg] (0x0400): Creating request for [ipa.example.com][3][1][name=admin]
    [sssd[pam]] [sss_dp_internal_get_send] (0x0400): Entering request [0x411d44:3:admin@ipa.example.com]
    [sssd[pam]] [sss_dp_get_reply] (0x1000): Got reply from Data Provider - DP error code: 1 errno: 11 error message: Offline
    [sssd[pam]] [pam_check_user_dp_callback] (0x0040): Unable to get information from Data Provider Error: 1, 11, Offline

3. **Бэкенд** обрабатывает запрос. Это может включать эквивалент выполнения команды ``kinit`` в процессе **krb5_child**, аутентификацию по **LDAP** или проверку по списку контроля доступа. После того, как запрос к **Бэкенду** завершится, результат отправляется обратно **собеседнику** **PAM**. Важно посмотреть также файл *krb5_child.log*, если установить уровень отладки ``debug_level = 10``, то в этот файл будет включаться также низкоуровневая информация для трассировки работы протокола Kerberos. Также можно имитировать аутентификацию вручную с помощью утилиты **kinit**.

4. **Ответчик** **PAM** получает результат и пересылает его обратно в модуль **pam_sss**. Сообщения об ошибке или статусе отображается в */var/log/auth.log*.
